…optimistic

Previously, this used a pessimistic recommendation. This switches
it to give an optimistic recommendation.

ruby/rubygems@de24c15410

…"lockfile"

Bundler treats "lockfile" as a special value for the version setting,
meaning "use the version recorded in BUNDLED WITH". BundlerVersionFinder
was passing the raw string to Gem::Version.new and raising ArgumentError
both from the env var added in #9538 and from .bundle/config.

ruby/rubygems@6576bb8e53

ruby/rubygems@fefe97c0bd

Adds four new hook points:
- before-fetch / after-fetch: fires in Source::Rubygems#download_gem
  around actual network downloads, avoiding noise from cache hits.
- before-git-fetch / after-git-fetch: fires in Source::Git#specs
  around fetch/checkout operations.

Based on the original proposal in #8162 with adjustments:
- Moved gem fetch hooks from fetch_gem_if_possible to download_gem
  so they only fire on actual network I/O.
- Dropped the source argument since spec.source provides it.
- Renamed git hooks to before-git-fetch / after-git-fetch for
  consistency with the existing before-*/after-* pattern.
- Removed GEM_BEFORE_FETCH/GEM_AFTER_FETCH from Source::Git#install
  since using gem fetch events for git sources is semantically
  inconsistent.

ruby/rubygems@34c4a46ef2

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Covers the four new hook events added in the previous commit:
before-fetch, after-fetch, before-git-fetch, after-git-fetch.

ruby/rubygems@a08ea29297

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Arrange events.rb by actual firing order so the file reads as a
timeline of bundler's lifecycle: Gemfile eval, install-all bracket
(with per-gem fetch, git fetch, and install nested inside), then
require-all bracket (with per-gem require nested inside).

Also clarify the git fetch hook docstrings: the hook fires around
both remote fetch and checkout, not only fetch.

ruby/rubygems@acc0659ffc

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…ilure

Wrap the fetch/checkout operations in begin/ensure so the after
hook fires even when the underlying fetch raises. This matches
the existing GEM_AFTER_INSTALL hook, which fires on both success
and failure paths (via internal error-to-state conversion in
ParallelInstaller#do_install).

Without this, plugins relying on before/after pairs for cleanup
or timing would see unbalanced hook invocations whenever a
network or checkout error occurs.

ruby/rubygems@d33e3eb4a4

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…or specs

doctor_spec.rb strict-stubs File.writable? and File.readable? with
specific paths, which was safe as long as the doctor command did
not trigger Plugin.hook. The new before-eval/after-eval hooks
fire during Bundler.definition, which the doctor command calls,
and Plugin.hook initializes Plugin::Index, which touches
Bundler.user_home and calls File.writable? on the test home path.
Those calls do not match the stubs and RSpec raises.

Match the existing File.exist? pattern and add and_call_original
fallbacks so unrelated paths fall through to the real methods,
while the specific stubs continue to control the paths under test.

ruby/rubygems@a8c04c4536

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

The hook receives a Bundler spec proxy (Bundler::EndpointSpecification
or Bundler::RemoteSpecification) that responds to the Gem::Specification
API but is not itself a Gem::Specification instance. Plugins doing
strict is_a? checks would break on the previous wording.

Also clarify the cache-hit language: the hook does not fire when the
initial download-cache check in fetch_gem finds the .gem already on
disk, but Bundler.rubygems.download_gem also has a race-protection
early return on the same path, which the previous wording obscured.

ruby/rubygems@93fe617ea8

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

To run with the revision specified in gems/bundled_gems file.

The git source exclusion in `find_source_requirements` introduced by
ruby/rubygems#9234 relies on `locked_requirements` to backfill the gap
for sources used only by --without groups. Without a Gemfile.lock —
e.g. an initial `BUNDLE_ONLY=ci bundle install` where a default-group
gem from a git source is shifted into the "excluded" set — that
fallback is absent, and the source's indirect dependencies fall
through to the default rubygems source, causing resolution to fail.

Gate the exclusion on `nothing_changed?` so it only applies when the
lockfile is guaranteed to cover the excluded sources.

Fix ruby/rubygems#9536

ruby/rubygems@89ed2bc9ef

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

ruby/rubygems@234e2b7d5f

72eb59d introduced these tests.